The present disclosure relates generally to interfaces which allow the use in one interpreted programming language of language constructs written in a different interpreted programming language. In particular, this disclosure relates to interfaces which would allow a user of a high-level script to integrate lower-level scripts written in different scripting languages.
Compiled languages cannot be used interactively. The standard use case is to write the code, compile the code, and then run the code. This is a good paradigm for a software developer who is writing an application, but it is not as useful for an engineer or mathematician who needs to explore and solve a problem.
Interpreted languages can be used interactively. An engineer can have a “prompt” where he/she types code and the code is interpreted and then executed while the underlying application is running. Examples of interpreted languages include Python, Ruby, etc.
Scripting languages are added to applications to allow a user to drive the application from a command prompt or text file. Interpreted languages can be used as scripting languages and hereinafter this disclosure will refer to interpreted languages that are used for scripting as “scripting languages”.
Python is an interpreted language. It has several implementations, including CPython and Jython. CPython is written in C language and is commonly called Python. Jython is written in Java.
Java is a compiled language that runs on a Virtual Machine. There are several scripting languages that are built on top of the Java Virtual Machine. These are commonly referred to as J-Based scripting languages. (Examples include Jython, JRuby, Groovy and Rhino.)
A proprietary J-based scripting language is known that is a domain-specific language designed for geometry manipulation and meshing (creating discrete representations). Also known is an application written in Java for geometric construction, analysis and manipulation, which is designed to be scripted. The underlying Java code defines many geometry operations. Engineers can then use these scripts to make use of specific geometry operations to solve their engineering problem. These scripts represent knowledge capture of the engineering process. There is a strong need to reuse these scripts. There is a need to be able to drive the aforementioned geometric construction application using these preexisting proprietary language scripts.
Consider a high-level engineering process that consists of several lower-level engineering processes. Each lower-level process may have already been written. An engineer needs to be able to write a high-level script that integrates the lower-level scripts. Since these scripts may be written in more than one scripting language, a way is needed to easily share the functions, classes, instances and objects that were created in the different scripting languages.
It is currently possible in existing scripting environments to share data between scripting languages, but to do so takes programming skill as well as knowledge of the underlying Java language. A solution to this problem should be designed for engineers, not for application developers, so the solution should not require additional programming/software development on the engineer's part.
Thus there is a need for a methodology that allows different engineers to program in different scripting languages and then share the code they write across these scripting languages without considering issues of the underlying language implementations. Preferably the solution will also include domain-specific languages.